1. Field of the Invention
The present invention relates to techniques for initializing software, such as device drivers for network interface controllers, in a host data processing system. More particularly, the invention relates to a process for loading a software product in host memory, and then optimizing the product for the particular architecture of the host data processing system.
2. Description of Related Art
Computer systems have been implemented according to a large number of variant architectures, where the architecture is defined as the hardware components, such as the CPU type, which make up the system and the software operating system which provides a platform for accomplishing a variety of applications.
The CPU type in a given architecture may include a kind of microprocessor which is used in the CPU. Microprocessor types include the "86" class of microprocessors, originating with and manufactured primarily by Intel Corporation. This class of microprocessors includes the models designated 8086, 8088, 80186, 80286, 80386, 80486, as well as any other microprocessor which shares substantially the same instruction set. Each microprocessor in this family uses a common subset of instructions but have unique capabilities which distinguish them from one another. Other microprocessor classes include the 68000 class provided by Motorola, and a variety of KISC processors made by a number of companies.
Operating system types include most commonly MS-DOS in a variety of versions, developed by Microsoft Corporation of Bellevue, Washington, and variants thereof. Also, the OS/2 operating system, the UNIX operating system and others have been developed for a wide variety of system architectures.
Thus, an architecture of a data processing system is defined by the hardware which makes up its central processing unit and related components, and the operating system software which provides a platform for running application software and the like. A manufacturer of add-on devices designed to handle a plurality of variant architectures must provide software for controlling the add-on devices which runs in each of the variant architectures. This software is typically referred to as a device driver. Therefore, typically prior art systems required a number of versions of device drivers written for each variant architecture for which the add-on device is intended to run. The user must be able to select which device driver applies to his data processing system, and the manufacturer must distribute a large number of versions. This requires an intelligent user for loading and initializing the device driver.
Alternatively, tradeoffs are made in the design of the device driver. For instance, if one is interested in accommodating only the 86 class of microprocessors, the device driver must be written in only the common subset of instructions which is executed by all of the processors in the class. Thus, data processing systems which use the high end versions of the 86 class have device drivers which do not use the capabilities of that system to their fullest extent.
To assist the user in identifying which microprocessor is used in a given data processing system, manufacturers of such microprocessors typically disclose techniques for recognizing the microprocessor in use. These techniques involve testing the functions of the microprocessor such that the results uniquely indicate which type is in use. These tests can be used for optimizing code usage by a particular microprocessor.
Computer architectures are typically designed with a limited amount of user accessible random access memory. For instance, the 86 class of microprocessors and the MS-DOS operating system were originally intended to be useful only with a base of 640 kilobytes of user accessible memory. This limitation represents a major memory usage limitation in certain applications of computers employing a given variant architecture.
Applications programs, including drivers, resident portions of operating systems, terminate and stay resident programs, and other software, must generally occupy a portion of this user accessible memory during operation of the computer. Where the computer is installed as a node of a local area network or the like, a certain amount of this memory space must be set aside for device drivers for the network interface. Thus, it is important to minimize the amount of space occupied by device drivers and the like in order to allow applications of the computer system maximum access to user accessible space.
Therefore, the designer who is intent on distributing software in executable form which must occupy a portion of the user accessible space in a computer system, must account for the variant architectures for which the particular device is intended to be used. One approach of doing so, the operating system is optimized for each particular variant and a selection is made by the user of the correct version of the device driver for his system to be loaded. In another approach, all optional versions are loaded into the limited user accessible space together, thereby using up more space than necessary. Alternatively, the device drivers are written with only the common subset of instructions available to all of the architectures for which the driver is written. In this case, the designer is not able to take advantage of the power and versatility of the more advanced architectures.
Accordingly, there is a need for a process for optimizing software for the particular variant host architecture without sacrificing advanced processes available to the advanced architectures, nor wasting user accessible space with versions of code that are not used in the particular host.